SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -
https://gyazo.com/c96b88f3d69e16bd94bec924f8e312e9
a.k.a SRE本
従来は DevとOps が別に分かれている
Dev: 新しい機能をリリースしてユーザーに届ける
Ops: ページャーを待つ間はサービスに問題が起きないように 求められるものはUNIXシステムの内部、ネットワーキング、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正
手作業で行っていたことを自動化するチームになった
運用50%という上限を設けている
運用の時間が超過したらチケットを差し戻す
可用性, レイテンシ, パフォーマンス, 効率性, 変更管理, モニタリング, 緊急対応, キャパシティプランニング に責任を負う
100%の信頼性を目標とすることは基本的には間違っている (99.999% -> 100% に費やす労力はユーザーに対した影響がない)
ユーザーが満足する可用性のレベルはどの程度か
可用性に満足できないユーザーに対しての代替策
可用性レベルを変更した時にユーザーの利用方法に何が起こるか
モニタリング
アラートに対してソフトウェアが対応を行い、人間がアクションを起こす必要があるものだけ通知を受けとる
モニタリングの出力は アラート、チケット、ロギング の3種類
キャパシティプランニング + プロビジョニング
プランニング
キャパシティの確保に必要なリードタイムを知る
突発的な需要の発生源を正確に織り込む
定期的な負荷テスト
キャパシティは高価なので必要な時に必要な量を素早くプロビジョニングする
Borg がサーバーをどのマシンで稼働させるか管理している CL(change list = pr)、レビュー、CIを使う リスク
管理
可用性のターゲットを決め、それを大幅に越えようとしない
越えようとすると、システムへの機能追加、負債の返済、運用コスト低減などを行うチャンスを失う
計測
リスク許容度
サービスが提供する機能と、市場におけるそのサービスの位置づけに依存する
YouTubeは2006年当時、機能開発の速度に重点を置いて低めの可用性に 可用性を上げるコストが費用対効果に見合うのか
ISPの典型的なエラー率は0.01%~1%。それより低いエラー率を目指しても可用性はノイズに紛れる
エラーバジェットの活用
エラーバジェットを使い切りそうな場合は新しい機能リリースを停止して修正/改善に取り掛かる
使い切るとリリースできないので、開発チームが自己統制できるようになる
データセンターの障害でも消費する
設定して公表する = ユーザーの期待を設定すること
明示されたものがないと、サービスへの過剰な信頼と信頼の損失のどちらにもつながる
主にリクエストのレイテンシ、エラー率、スループットをみる
殆どの場合、平均より分布をみる
プロダクションサービスを動作させることに関係する
手作業、繰り返される、自動化出来る、長期的な価値を持たない、サービスの成長に比例するもの
これを減らしてサービスをスケールさせるのがサイトリライアビリティエンジニアリングで、最低50%をこの作業にあてる
モニタリング
実際に起きている問題 (正常に動作していない等の症状)
RED method
Rate (number of requests per time)
Errors
Duration
ログやHTTPエンドポイント等システム内部を調査する機能に依存
USE method
Utilization
Saturation
Errors
Latency
Traffic
Errors
Saturation
可能な限りシンプルに、やりすぎない
ほとんど実施されないデータの収集、集計、アラートの設定は削除すべき
ページが来るたびに緊急事態という感覚を保って対応する
エンジニアの作業が最小限で済むように自動化する
出来る限り早くロールアウトし、バージョン間の変更を少なくする
初期の段階からやろう
https://gyazo.com/c2e58686fec38cab2dcd7af0b027b766
サービスの信頼性の階層
SREの時間の25%以上にならないようにする
負担を軽くするリソースを理解する
明確なエスカレーションパス
インシデント管理手順
全てのエンジニアが四半期に1~2回はオンコールを担当できるように
Googleでは全社規模のディザスタリカバリトレーニングを年に1回行っている ロードバランシング
リクエストをキューに入れている場合、そのキューのサイズはスレッドプールのサイズと比べて短めの方が良い
キューに入り切らなかった場合はクライアントがリトライしてくれる
対応
サーバーが過負荷状態に近づくにつれてトラフィックをドロップすることで負荷を下げる
RAMを使い切ったりヘルスチェックに失敗することでレイテンシの極端な悪化等を防ぎ、有用な処理をできる限り継続する
リクエストが一定数超えたら503返すとか
レスポンスの品質を落とす等、処理量を減らす
画像/動画の品質下げるとか
リトライ
自動リトライ
負荷になることを防ぐ
明確なレスポンスコードの指定
再実行や再起動回数の制御、